![[アップデート] AWS Config マネージドルールに 28 ルールが追加され、全部で 162 種類になりました！多い！](https://devio2023-media.developers.io/wp-content/uploads/2019/05/aws-config.png)
[アップデート] AWS Config マネージドルールに 28 ルールが追加され、全部で 162 種類になりました！多い！
コンバンハ、千葉（幸）です。
AWS Config マネージドルールが一気に 28 種類も追加されました！
これで合計は 162 種類になりました。このくらいの数だとコンプリートしたくなりますね！（※ Config ルールにコンプリートという概念はありません。）
目次
AWS Config マネージドルールとは
マネージドルールとは、ユーザーが AWS Config ルールを作成する際にソースとして指定できるルールのうち、 AWS が提供しているもののことを指します。
以下のようなイメージです。
Config ルールって何？という場合には、以下のエントリにて上記の絵を含めて説明していますのであわせてご参照ください。
また、AWS Security Hub を使用してスタンダードによる評価を有効化した場合、その多くはマネージドルールを使用して評価が行われます。こういった他の AWS サービスでも使用されています。
AWS Config ルールにかかる料金は以前と比較してお安くなっていますので、活用していきたいですね。
どんなマネージドルールが増えたのか
マネージドルールの一覧は以下のページで確認することができます。
List of AWS Config Managed Rules - AWS Config
日本語のドキュメントはまだ更新が入っていなかったので、英語版との差異を洗い出した結果、以下が追加されたことが確認できました。
| マネージドルール名 | チェック観点の概要 |
|---|---|
| account-part-of-organizations | アカウントがOrganizationsに所属しているか |
| alb-http-drop-invalid-header-enabled | 有効ではないヘッダーフィールドを持つ HTTP ヘッダーがロードバランサーによって削除されるか |
| alb-waf-enabled | ALBでWAFが有効になっているか |
| cloudfront-default-root-object-configured | CloudFrontディストリビューションにデフォルトのルートオブジェクトが設定されているか |
| cloudfront-origin-access-identity-enabled | S3 OriginタイプのAmazon CloudFrontディストリビューションにOrigin Access Identity（OAI）が設定されているか |
| cloudfront-origin-failover-enabled | CloudFrontでオリジングループが設定され、ディストリビューションに2つ以上のオリジンが設定されているか |
| cloudfront-sni-enabled | CloudFrontディストリビューションがカスタムSSL証明書を使用しており、SNIを使用してHTTPSリクエストを処理するように構成されているか |
| cloudtrail-security-trail-enabled | セキュリティのベストプラクティスで定義されたAWS CloudTrailトレイルが少なくとも1つあるか。（グローバルサービスイベント記録、マルチリージョン、ログファイル検証、KMSキー暗号化、読み取りと書き込み記録、レコード管理、管理イベントを除外しない） |
| cw-loggroup-retention-period-check | Amazon CloudWatch LogGroupの保持期間が特定の日数に設定されているか |
| dax-encryption-enabled | Amazon DynamoDB Accelerator（DAX）クラスターが暗号化されているか |
| dynamodb-in-backup-plan | Amazon DynamoDBテーブルがAWSバックアッププランに存在するか |
| ebs-in-backup-plan | Amazon EBSボリュームがAWS Backupのバックアッププランに追加されているか |
| efs-in-backup-plan | Amazon EFSファイルシステムがAWS Backupのバックアッププランに追加されているか |
| ec2-imdsv2-check | EC2インスタンスメタデータバージョンがインスタンスメタデータサービスバージョン2（IMDSv2）で構成されているか |
| eks-endpoint-no-public-access | Amazon EKSエンドポイントがパブリックにアクセス可能になっていないか |
| eks-secrets-encrypted | Amazon EKSクラスターが AWS KMS により暗号化された Kubernetes secrets を持つよう構成されているか |
| elasticsearch-node-to-node-encryption-check | Amazon ElasticSearch Serviceノードがエンドツーエンドで暗号化されているか |
| elb-cross-zone-load-balancing-enabled | Classic Load Balancer（CLB）でクロスゾーン負荷分散が有効になっているか |
| elb-tls-https-listeners-only | Classic Load BalancerがSSLまたはHTTPSリスナーで構成されているか |
| iam-no-inline-policy-check | IAMユーザー、IAMロール、またはIAMグループにインラインポリシーが設定されていないか |
| rds-cluster-deletion-protection-enabled | Amazon RDS クラスターで削除保護が有効になっているか |
| rds-instance-deletion-protection-enabled | Amazon RDS インスタンスで削除保護が有効になっているか |
| rds-instance-iam-authentication-enabled | Amazon RDS インスタンスで IAM認証 が有効になっているか |
| rds-logging-enabled | Amazon RDS の各種ログ出力が有効になっているか |
| redshift-backup-enabled | Amazon Redshift クラスターの自動スナップショットが有効になっているか |
| rds-in-backup-plan | Amazon RDSデータベースがAWSバックアップのバックプランに存在するか |
| waf-classic-logging-enabled | AWS WAF クラシックのグローバル Web ACLでロギングが有効になっているか |
| wafv2-logging-enabled | AWS WAF v2 のリージョナルおよびグローバル Web ACLでロギングが有効になっているか |
新機能に関するルールが増えているようにも見えつつ、クラシックなサービスに関するルールも追加されていますね。こういう観点でチェックしたかったんだよなーというものがある方は、これらのマネージドルールを使用した Config ルールを活用するのもよいでしょう。
やってみた
せっかくなので新しく追加されたルールを用いて Config ルールを作成してみます。
今回は……、 iam-no-inline-policy-check 、キミにきめた！
IAMユーザー、グループ、ロールにインラインポリシーが設定されていないかを確認するルールです。現状ではインラインポリシーでなく管理ポリシーを使用することが推奨されています。（個人的にはインラインポリシーの採用は要件によってはまだまだアリだと思っています。）
管理ポリシーとインラインポリシー - AWS Identity and Access Management
AWS Config の画面から [ ルールを追加 ] を押下します。
ソースとして指定できるルールの一覧が表示されるため、今回対象とする iam-no-inline-policy-check でフィルタをかけて選択します。「新規」のアピールが気持ちいいですね。
ルールの詳細設定画面に遷移します。今回は自動的に入力された状態のまま次に進みます。名前や説明を独自に入力したり、評価対象とするリソースを絞ることもできます。
Config ルールにより非準拠と評価されたリソースに対する修復アクションを設定することもできます。修復アクションは AWS Systems Manager オートメーションドキュメントにより実行されます。今回は特に指定しません。
作成が完了すると、ルール一覧画面に追加されていることが確認できます。（現状ここでルール名でフィルタリングできないのがちょっとつらみがあります。。）
ルールの詳細から、評価対象のリソースと、それぞれの準拠状況を確認することができます。
ルールに応じてリソースの設定状況を確認したり、必要に応じて修復アクションを行うことができます。修復アクションを紐づけていればこの画面から実行も可能ですし、リソースを直接手動で修正することで準拠状態に遷移させることもできます。
要件に応じた Config ルールを活用してください。
終わりに
新たに追加された AWS Config マネージドルールについて確認しました。
個々のリソースを一定の基準でチェックしていくのはなかなかしんどいの、こういった仕組みを活用して適切な設定状態を維持していきたいですね。
マネージドルールが追加されたことで、それらを使用する AWS Config 適合パックや AWS Security Hub にもアップデートがあったりしないかな!?と期待が膨らみます。
セキュリティには終わりがないですから、どんどん便利な仕組みが増えていって欲しいですね。
以上、千葉（幸）がお送りしました。
